home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000209_owner-urn-ietf _Tue Nov 26 15:34:56 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA13817 for urn-ietf-out; Tue, 26 Nov 1996 15:34:56 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA13794 for <urn-ietf@services.bunyip.com>; Tue, 26 Nov 1996 15:34:24 -0500
  3. Received: from iberia-c.it.earthlink.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA18685  (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 15:34:21 -0500
  5. Received: from [153.35.78.27] (Cust27.Max18.Boston.MA.MS.UU.NET [153.35.78.27]) by iberia.it.earthlink.net (8.7.5/8.7.3) with ESMTP id MAA11660; Tue, 26 Nov 1996 12:33:10 -0800 (PST)
  6. X-Sender: tows@mail.earthlink.net
  7. Message-Id: <l03010902aec05c394076@[153.35.78.151]>
  8. In-Reply-To: <96Nov26.063616pdt."135"@palimpsest.parc.xerox.com>
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset="us-ascii"
  11. Date: Tue, 26 Nov 1996 03:37:05 -0500
  12. To: Larry Masinter <masinter@parc.xerox.com>
  13. From: Towsner <tows@earthlink.net>
  14. Subject: Re: [URN] Persistence as part of URN framework
  15. Cc: urn-ietf@bunyip.com
  16. Sender: owner-urn-ietf@services.bunyip.com
  17. Precedence: bulk
  18. Reply-To: Towsner <tows@earthlink.net>
  19. Errors-To: owner-urn-ietf@bunyip.com
  20.  
  21. At 8:36am -0500 11/26/96, Larry Masinter wrote:
  22. ># All I wanted was an *optional* persistence value to be possible, so that the
  23. ># URN resolution service could indicate the longevity of the resolver (not the
  24. ># URN), at least until the longevity was extended once the people managing it
  25. ># were willing to commit to a longer running service.
  26. >
  27. >...
  28. >
  29. ># No-one seems to be able to get their head round the fact that such expiry
  30. ># times are meaningless if you don't know how long you will be able to resolve
  31. ># URNs which end up pointing to HTTP, but might point to another scheme later
  32. ># to keep them alive. I think the problem is that people just aren't thinking
  33. ># in terms of how much the world will change in the decades ahead. All I'm
  34. ># trying to propose is a way to avoid having to poll for broken resolution
  35. ># services in the future.
  36. >
  37. ># I give up.
  38. >
  39. >No URN resolution protocol that doesn't explicitly deal with the
  40. >issues of what happens when providers quit, merge, or split can
  41. >seriously claim to address URN requirements.
  42. >
  43. >A protocol can be marked as 'Experimental', but even Experimental
  44. >drafts can be marked to clearly indicate what parts of the problem
  45. >they're not handling. The experiment then can help determine how
  46. >serious, in practice, the problem really is.
  47.     I think some type of persistance check is important.  The ability
  48. to mark information as transient should definately be part of the URN
  49. framework.
  50.  
  51. --
  52. <Insert witty signature here>
  53. -Henry Towsner <tows@earthlink.net>
  54.  
  55.